sonic-net#26175) (sonic-net#26176)

### Description of PR

Summary:
Fixes sonic-net#26175

Temporarily skip the whole `bgp/test_bgp_suppress_fib.py` module for the
suppress-fib-pending **dynamic-toggle race**.

The module toggles `suppress-fib-pending` dynamically at runtime (via
the shared `config_bgp_suppress_fib()` helper, no `config reload`). That
triggers a race between **orchagent, fpmsyncd and FRR** where routes are
intermittently **not marked offloaded in FRR** / **not propagated to the
upstream VM** within the wait window, failing essentially every case in
the module.

The root-cause fix makes `suppress-fib-pending` **static** (takes effect
only after a `config reload`), removing the race —
[sonic-swss#4333](sonic-net/sonic-swss#4333),
[sonic-buildimage#26151](sonic-net/sonic-buildimage#26151),
[sonic-utilities#4361](sonic-net/sonic-utilities#4361),
[sonic-mgmt#22916](sonic-net#22916),
[SONiC#2335](sonic-net/SONiC#2335).

> **The product fix is master-only and is not backported.** Because of
that, the skip uses **two different lift semantics**, expressed as
separate conditions:
>
> - **`master`** — gated on the tracking issue: `release in ['master']
and https://github.com/sonic-net/sonic-mgmt/issues/26175`. When the fix
lands on master and sonic-net#26175 is closed, the skip **auto-lifts** on master
and coverage returns — no manual edit needed.
> - **`202505` / `202511` / `202605`** — a plain `release in [...]`
condition with **no issue gate**. These branches never receive the
product fix, so the module is skipped for the life of the branch (same
nature as the existing pre-202411 "not supported" condition).
>
> **Per-branch effect still requires cherry-picking this skip.** Each
release branch's nightly runs its own `sonic-mgmt` checkout, so this
YAML change must be cherry-picked to 202505/202511/202605 for the skip
to take effect there. The identical diff matches on each branch via its
own `release` token.
>
> If a release branch ever does receive the product fix, drop that
branch's token from the `release in [...]` list — a deliberate
per-branch edit. sonic-net#26175 tracks the lifecycle.

### Type of change

- [ ] Bug fix
- [x] Testbed and Framework(new/improvement)
- [ ] New Test case
    - [ ] Skipped for non-supported platforms
- [ ] Test case improvement

### Back port request

- [ ] 202205
- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [x] 202505
- [x] 202511

(also 202605 — not listed in the template checkboxes; cherry-pick
required there as well.)

### Approach
#### What is the motivation for this PR?

The `test_bgp_suppress_fib` module is a persistent nightly-noise source
across master and the active release branches. The dynamic runtime
toggle of `suppress-fib-pending` races orchagent/fpmsyncd/FRR, so routes
are intermittently left un-offloaded / un-propagated and nearly every
case in the module fails intermittently. Skipping the module de-noises
the nightly signal while the product-layer fix rolls out on master.

#### How did you do it?

Extended the existing `bgp/test_bgp_suppress_fib.py` skip block with
`conditions_logical_operator: or` and split the affected releases by
lift semantics:

```yaml
conditions:
  - "release in ['201811', '201911', '202012', '202205', '202211', '202305', '202311', '202405']"
  - "release in ['202505', '202511', '202605']"
  - "release in ['master'] and sonic-net#26175"
```

The `conditional_mark` plugin replaces the issue URL with `True`/`False`
based on the issue's open/closed state and `eval()`s the condition, so
the master line auto-lifts when sonic-net#26175 closes while the release-branch
line stays permanent. (The same file already uses the `<expr> and
<issue-url>` form for the `asic_type in ['vs'] and sonic-net#14449` conditions.)

#### How did you verify/test it?

- `tests_mark_conditions.yaml` parses cleanly and passes the
`check_conditional_mark_sort.py` pre-commit hook.
- Simulated the `conditional_mark` evaluation for each `release` value:
  - issue **open**: master + 202505/202511/202605 all skip;
- issue **closed**: master unskips, 202505/202511/202605 remain skipped
— matching the intended lift semantics.

#### Any platform specific information?

None — the skip is keyed on `release` only (all ASICs/topologies),
matching the all-vendor nature of the race.

#### Supported testbed topology if it's a new test case?

N/A — not a new test case; module skip only.

### Documentation

N/A

Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: ssithaia-ebay <ssithaian@ebay.com>